In a cloud computing environment, computing is delivered as a service rather than a product, whereby shared resources, software and information are provided to computers and other devices as a metered service over a network, such as the Internet. In such an environment, computation, software, data access and storage services are provided to users that do not require knowledge of the physical location and configuration of the system that delivers the services. The functions of the cloud computing environment are performed by a data center, which includes various types of hardware components (e.g., storage controllers, network switches, physical compute machines or nodes) stored in racks.
An administrator of the cloud computing environment may build a reusable pattern which defines the topology and application environment used to service the customer (i.e., the user receiving the services provided by the cloud computing environment) as well as satisfies the customer requirements, such as application and processing requirements. The pattern is an abstract model of the topology and application environment that encapsulates the installation, configuration and management of middleware and applications, such as the middleware and applications that run on virtual machines in the physical compute nodes. Such a pattern can be deployed repeatedly thereby avoiding the need to provision these environments individually and manually.
Currently, a pattern may be deployed on multiple racks (commonly referred to as a “domain”) to increase support for high availability and disaster recovery. For example, a pattern consisting of a set of virtual machines and the software running on these virtual machines is deployed on each rack within a “domain” of racks. In this manner, the workload handled by the virtual machines of the pattern on a rack that fails may be routed to be handled by the virtual machines of the pattern on another rack of the domain.
The content of the pattern, such as the operating system images, middleware binaries and other artifacts, may be obtained from external repositories. While fetching such content from external repositories may be possible, the performance of the system may be diminished due to the time it takes to retrieve such content, especially if such content (e.g., operating system image) is stored in very large files (e.g., multiple gigabytes). Furthermore, a rack may be rendered non-operational in situations where the external repository failed or the network connection to the external repository from the rack was interrupted. As a result, there has been a preference to store the content needed for pattern deployments on all of the racks of the domain locally.
However, there is not currently a means for determining which content is necessarily needed for pattern deployment on these racks. Neither is there currently a means for transferring such content from one of the racks of the domain to the other racks of the domain so that they all contain the same content in an order based on priority. Since a rack may fail or the network connection to the rack may be interrupted, it may be wise to transfer those contents that are most important prior to those that are less important.